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1.0  SCOPE 

This  document  provides  detailed  information  which  is  in  addition  to.  or  a  funher 
explanation  of,  the  information  presented  in  Delivery  Order  022.  Contract  DAAJ09-89-D-(X)21, 
Advanced  Integrated  Aircraft  Survivability  Equipment  Analysis  Final  Report. 

2.0  DETAILED  INFORMATION 

2.1  COMMUNICATION  INTERFACE  AND  PROCESSOR  COST 

Defining  individual  comptment  costs  of  processors  and  interconnects  does  not  illustrate  the 
true  cost  impact  of  the  component  For  example,  VME  and  MIL-STD-1SS3B  are  the  only  two 
individual  options  for  interconnects  and  processors  with  a  significant  per  pan  cost  savings.  VME 
is  undesirable  for  reasons  other  dian  cost,  while  MIL-STD>1553B  was  selected  as  the  best  Local 
Area  Network  (LAN)  for  AIASE.  Per  pan  costs  for  all  of  the  other  options,  PI-Bus  vs. 
Futurebus+  and  R4()00  vs.  8()960MX,  will  be  similar. 

The  average  cost  of  a  SEM-E  module  in  the  late  199(ys  has  been  estimated  at  $17,0(X) 
(1987  dollars  used  throughout).  The  primary  driver  in  module  cost  is  normally  memory  and 
manufacturing.  A  processor  or  interface  device  typically  represents  only  S%  to  10%  of  the  total 
module  purchase  cost  The  High  Speed  Data  Bus  (HSDB)  is  an  exception  due  to  the  high  number 
of  hybrid  components.  The  HSDB  interconnect  components  may  represent  more  than  S0%  of  the 
module’s  estimated  $28,(X)0  cost  In  addition,  a  HSDB  requires  a  coupler  external  to  the  module 
which  is  significantly  mtne  complex  than  a  1553  bus  coupler  (see  Hgure  2-1).  The  cost  of  the 
coupler  is  highly  dependent  on  the  number  of  terminals  on  the  HSDB. 

Rather  than  procurement  costs,  the  more  significant  cost  driver  for  n»st  components  is  the 
level  of  integration  and  suppon  difficulties  introduced.  Each  con^nent  type  must  be  designed, 
simulated,  prototyped,  integrated  with  a  prototype  module  (including  integration  with  software 
drivers,  operating  systems,  and  applications),  tested,  redesigned  (usually),  integrated  with  a 
production  module,  tested,  and  finally  used  in  the  system.  At  that  time  the  component  must  be 
supported  by  field  test  equipment  and  the  logistics  system.  This  cycle  must  be  followed  for  each 
component  used.  If  common  components  are  used,  the  development  cost  is  paid  only  once  or  is 
shared  among  multiple  modules.  The  support  costs  are  minimized  because  fewer  part  types  and 
less  special  test  equipment  is  needed.  If  the  components  conform  to  an  industry  standard,  then 
manufacturers  may  be  willing  to  invest  in  the  eariy  stages  of  the  cycle  widi  the  hopes  of  developing 
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a  better,  yet  compatible,  component.  This  would  be  similar  to  the  current  availability  of  80X86 
processors  from  non-Intel  manufacturers. 


TRANSMIT 


MODULE 


RECEIVE 


nCURE  M.  "PA55iVE"OynCAL  COUPLING  TO  IMPLEMENT 

A  LINEAR  BUS 


The  cost  benefits  of  commonality  are  different  for  the  different  integration  levels 
(cmnponent,  module,  subsystem,  system,  platform,  service,  DoD).  The  Institute  for  Defense 
Analysis  (IDA)  Commonality  Study  and  the  Onnanche  responses  to  the  Office  of  the  Secretary  Of 
Defense  (OSD)  Commonality  Quesdonnaire  reveal  that  the  life  cycle  cost  benefits  decrease  as 
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commonality  is  applied  to  higher  levels.  For  example,  a  common  module  within  a  subsystem 
provides  a  higher  cost  beneHt  than  a  conunon  module  applied  between  platforms.  Although  only 
commonality  at  the  module  level  was  studied,  an  extrapoladon  to  the  component  level  can  be  nuuie. 
The  reason  for  decreasing  cost  benefits  as  commonality  is  ^lied  at  higher  levels  is  due  primarily 
to  the  increased  complexity  of  configuradon  management  and  the  broadening  requirements  which 
must  be  met  by  the  module. 

The  conclusion  is  that  cost  savings  are  best  realized  by  selecting  the  most  mature 
components  that  will  meet  similar  requirements.  The  following  paragr^hs  and  Table  2<1  provide 
information  on  the  development  state  of  each  option.  The  final  report  provides  details  regarding 
the  capabilities  of  each  option. 

The  PI-Bus  maiicet  is  tied  directly  to  military  aviation  programs.  With  the  uncertainty  of 
Comanche  production,  production  PI-Bus  parts  may  be  limited  to  the  Delco  chip  developed  for 
F-22  and  the  Tl  chip  developed  for  the  F-16  Modular  Missitm  Conq)uter  (MMQ.  Any  changes  in 
dtese  programs  would  have  serious  effects  on  the  cost  and  availability  of  PI-Bus  parts. 

Futurebus-t-  is  currently  available  only  in  small  quantities  as  multi-chip  implementations 
without  full  functionality.  None  of  these  implementations  are  currently  qualified  for  the  miliuuy 
environment.  The  market  pressure  from  the  Navy's  Next  Generation  Computer  Resources 
(NGCR)  program  will  ensure  the  availability  of  military  Futurebus-t-  parts,  but  the  available 
protocol  functions  may  be  limited. 

The  VME-Bus  is  cuirently  available.  Although  it  is  a  clear  winner  on  cost,  it  does  not  rate 
favorably  in  other  criteria. 

The  MIL-STD-1553  Bus  is  currently  availi^le  and  is  a  much  simpler  technology  than  Hi^ 
Speed  Data  Bus.  The  costs  of  a  1553  bus  implementation  are  significantly  less  (70%  to  80%)  than 
that  of  the  HSDB. 
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TABLE  2-1.  COMMUNICATION  INTEEFACE  AND  PROCESSOR  COST 

FACTORS _ 


MIL 

PROGRAMS 

SPEC 

LEVEL 

■uEnizufl 

1333 

None 

Veiy  Many 

mu 

Yes 

Now 

None 

F-22.  RAH-66 

SAEAS4074.SAE 
AIR42S8Un 
Handbook.  JUWG 

Complete 

Yes 

Mid/laic  90‘s 

Pl-Bus 

None 

F-22.  RAH-66. 
F-16 

Complete 

Yes 

Mid/laie  90‘s 

FunBebut-** 

Work-stetions 

Many  Expected 

SEM-E  Pipfile 
Due  in  Late 
1992 

Yes 

1992/1993  for 
Commercial 

VME 

Many 

vnA 

Yes 

Now 

TM-Bus 

Boetns  777, 
Test  Eouinnent 

F-22.  RAH-66. 
F-16 

Yes 

Early/mid  90's 

SEE  1394 

Apple 

None 

No 

Mid/late  90‘s 

R3000/R4000 

Work-ststions 

F-16 

M  1  f  1  M 

Yes 

Now 

80960MX 

None 

RAWG 

Complete 

Yes 

Now 

The  Hiyh  Sneed  Data  Bus  is  in  a  situati<Hi  sinflar  to  that  of  the  PI-Bus.  It  is  mainly  driven 
by  militaiy  aviation  programs,  with  Comanche  and  F-22  the  primaiy  proponents.  Production  parts 
for  a  HSDB  are  tied  to  these  two  programs.  Again,  with  the  uncertainty  of  Comanche  production, 
production  HSDB  parts  may  be  limited  to  the  Harris  parts  developed  for  the  F'22. 

The  currently  planned  military  TM-Bus  implementations  arc  an  integral  part  of  a 
maintenance  controller  function  that  resides  withia  a  Multi-Chip  Module  (MCM).  There  are 
commercially  planned  implementations  that  are  separate  devices  that  interface  to  a 
processor/controller.  There  are  efforts  underway  to  make  the  protocol  and  physical  layer 
specirications  for  the  commercial  and  military  TM-Buses  the  same.  If  this  occurs,  the  market  will 
apply  downward  pressure  on  the  cost  and  availability  of  a  TM-Bus  device.  This  will  occur 
irrespective  of  the  militaiy  demands. 

The  TFBE  1394  Serial  Bus  is  currently  an  electrical  specification  without  a  protocol.  The 
NGCR  program  is  backing  this  interconnea  and  Apple  computer  is  proposing  to  use  it  in  their  next 
generation  of  computers.  There  are  currently  no  mifitary  platforms  specifically  backing  the  1394 
bus.  There  are  no  manufacturers  publicly  planning  to  make  devices  available,  therefore  no  cost 
information  is  available. 

The  MTPSro  R3nOQ  processor  is  used  in  mdtiple  military  configurations,  including  on  a 
SEM-E  module  in  the  F- 16  MMC.  It  is  acknowledged  as  one  of  the  commercial  industry  standards 
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in  the  workstation  aiena.  The  MIPSCQ  R4QQQ  is  a  foUow-on  to  the  R3000  and  is  cuirently 
available  in  workstations  from  Silicon  Graphics.  The  R40(X)  has  been  proposed  for  numerous 
military  applications.  Multiple  manufacturers  are  working  on  a  military  qualified  R4000.  The 
commercial  market  forces  will  drive  the  cost  and  availability  oi  this  processor. 

The  Intel  80960MX  processor  is  used  on  the  F-22  and  the  RAH-66  and  has  been  proposed 
on  numerous  military  products.  It  is  currently  available  fhmt  Intel  only  in  snudl  quantities.  The 
cost  and  availability  of  the  960  is  tied  to  the  F-22  and  RAH-661. 

HIGH  SPEED  DATA  BUS  OPTICAL  COUPLERS 

Two  LAN  candidates  were  considered  to  supptxt  the  inter-ASE  communication  between 
the  Integration  Processor,  ATIRCMS,  ATRJ,  AOCMS,  and  AVR-2.  MIL-STD-1S53B  is  a  well 
<kx;umented  and  understood  linear  protocol,  implemented  on  a  two  wire  electrical  medium,  and 
(^jerating  at  a  1  MHz  bit  rate.  The  HSDB  is  a  linear  protocol  iiiq)lemented  on  an  optical  fiber 
medium  which  can  operate  at  a  SO  MHz  bit  rate. 

Unlike  electrical  traces  in  a  backplane,  optical  fibos  do  not  naturally  form  a  linear 
interconnecL  Fibers  transmit  light  unidirectitHially  from  an  eminer,  such  as  an  LED,  to  a  light 
sensing  receiver  (photo-diode).  Two  fibers  are  required  to  facilitate  duplex  communication.  To 
implement  a  linear  protocol  on  an  inherently  point-to-^xnnt  medium,  a  coupling  device  is  required 
to  "split"  the  light  emanating  from  one  light  source  into  multiple  fibers  connected  to  the  receiver 
pins  of  the  terminals  on  the  HSDB.  This  is  logically  depicted  in  Figure  2-1. 

Two  types  of  couplers  are  available.  A  passive  coupler  uses  splices  to  ensure  that  all 
transmitters  have  optical  paths  to  all  receivers.  They  require  no  re-generation  or  re-timing  of 
signals  and  are  therefore  simpler  and  less  costly  than  a  coupler  that  actively  receives  and  re¬ 
transmits.  There  is  a  limited  optical  power  budget  bounded  by  the  power  available  at  the  light 
source  and  the  sensitivity  of  the  optical  receivers.  Each  splice  and  connector  between  the 
transmitter  source  and  receive  represents  a  power  loss.  The  more  termiiutls  on  a  HSDB,  the  more 
splicing  required  to  inqilement  the  linear  connectivi^.  Thus,  passive  couplers  are  generally  limited 
to  6  or  less  terminals.  For  systems  with  a  larger  terminal  cmmt,  active  couplers  are  required  to 
"boost"  the  q;>tical  power.  The  AIASE  maximum  terminal  count  would  be  5  (i.e.  4  AT  systems 
and  1  IP). 
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The  type  of  coupler  is  a  system  decision  based  on  the  total  opdcal  budget  available  for  the 
selected  HSDB  modules.  In  general,  a  given  HSDB  module  will  woik  with  either  an  active  or 
passive  coupler,  as  long  as  the  system  power  budget  is  not  exceeded. 

23  ARCHITECTURE  EVALUATION  CRITERIA 

As  stated  in  D.0. 022,  paragraph  9. 1.2,  scnne  criteria  for  the  architecture  evaluation  were 
eliminated  because  they  woe  not  discriminating.  This  statement  was  made  in  the  context  of  the 
architectural  element  discussion  with  the  intent  being  that  some  architectural  criteria  are  not 
discriminating  because  the  options  are  being  developed  within  the  framework  of  the  ongoing  AT 
system  programs.  These  options  are  evaluated  by  the  AT  system  developers  based  on  their 
perceived  requirements.  For  instance,  the  AT  system  architecture's  floating  point  capability  is 
being  designed  to  meet  the  resident  algorithms'  ftoadng  point  requirement,  and  thus  the  ciy)ability 
will  not  be  a  discriminating  factor  between  architecture  options. 


For  the  AIASE  architecture,  the  evaluation  criteria  was  categorized  into  processing, 
interconnect,  enclosure,  strftware.  and  front-end  elements,  hi  the  system  development  cycle, 
pertinent  criteria  are  used  to  assess  the  system  elements.  A  draft  list  of  potential  crimria  for  each 
element  is  provided  in  Table  2-2. 


TABLE  2-2.  POTENTUL  CRITERIA  FOR  SYSTEM  ELEMENTS 


MIPS  rating,  MOPS  rating,  MhLOPS  raung,  memory  access  time 
required,  cache  size,  intermpt  latency,  context  switch  time,  virtual 
addiessinK  capability,  security  features,  nuilt  tolerance 

1  INTERCONNECT 

As  provided  in  D.0. 022  Final  Report 

SOFTWARE 

Strftware  develc^ment  system  toots  (requirements  to  design  and  design  to 
code  traceability,  language  sensitive  editor,  host  conmiler-debugger- 
simulatOT-evaluator,  target  compiler,  multiuser  target  debugger,  target 
loader,  etc),  embedded  processor  support  (run  time  system,  metric), 
compiler  system  expansion  fmtor  rating,  compiler  system  optimization 
effo^eness 

Specific  to  each  front  end  but  may  include  aperture  size,  mounting 
restrictions,  shielding,  A^  efBciency,  digital  data  rate 

2.4  LOWER  LEVEL  TRADE-OFFS 


The  architecture  evaluation  documented  in  the  AIASE  Final  Report  concentrated  on  the 
interconnects.  The  draft  criteria  were  considered  for  the  other  architectural  elements,  but  it  was 


asceitained  that  a  detailed  assessment  is  best  perftnmed  at  lower  levels.  As  an  example,  an  ATRJ 
algorithm  developer  specify  a  worst  case  interrupt  latency  to  service  an  RF  pulse  report.  The 
nwdule  developer  will  assess  designs  against  the  interrupt  latency  requirement.  The  internal 
interrupt  latency  of  a  module,  while  very  important  to  executing  the  algorithm,  is  not  a  crucial 
parameter  for  the  system  architect.  The  system  architect  relies  on  the  algorithm  developer  and  the 
OKxiule  designer  for  their  assessments  of  these  elements.  Similarly,  enclosure,  software,  and 
firont-end  assessment  is  best  performed  by  the  experts  in  those  areas. 

The  AIASE  survey  analysis  identified  areas  that  the  AIASE  architecture  definition  should 
address  to  arrive  at  common  solutions.  Among  these  issues  were  power,  form  factor,  two-level 
maintenance  suppon,  general  purpose  processor  type,  software  development  systems,  operating 
system  services,  maintenance  controller  q)eration,  and  interconnects.  Eariy  coordination  between 
the  AT  system  architects  and  the  AIASE  system  designers  will  mitigate  future  interoperability  and 
integration  problems.  In  addition,  the  AIASE  study  includes  an  integration  process  not 
investigated  by  the  current  ATASE  programs.  General  purpose  processing  requirements  were 
assessed  based  on  the  integration  process  algorithm  requirements. 

The  selection  of  interconnects  was  identified  as  the  most  important  task  of  the  system 
architect  In  any  open  architecture  definition,  the  first  step  to  facilitating  interoperability  is  to 
ensure  that  standard  interconnects  are  used.  A  system  architect  can  selea  interconnects  that  meet 
the  expected  functional  communication  requirements.  The  requirement  to  use  these  standard 
interconiwcts  are  then  levied  on  the  module  designers.  The  benefit  of  this  is  threefold. 

1 .  The  system  integration  will  be  easier  because  all  modules  have  been  designed  to  use 
standard  interconnects. 

2.  The  module  supplier  is  allowed  freedom  in  the  internal  module  design  u>  apply  their 
particular  expertise.  Specifying  down  to  the  lower  levels  tends  to  take  the  system 
engineer  out  of  his  area  of  expertise  and  waste  the  suppliers'  expertise. 

3.  The  life  cycle  costs  are  reduced  because  all  module  interfacing  is  performed  on  standard 
interconnects. 

As  an  example  of  this  process,  a  system  architect  specifies  appropriate  standard 
interconnects  for  modules  required  to  interoperate.  The  EW  processing  expen  builds  the  optimal 
processor  while  communicating  off-module  via  the  standard  interconnect.  This  minimizes 
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integration  risk  and  simplifies  module  I/O.  Open  architectures  also  facilitate  easy  insertion  :tate- 
of-the-an  technology.  A  rigid  common  module  definition,  however,  tends  to  shackle  the 
supplier's  innovation  and  eliminates  functionality  from  any  competition. 
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